這是熱騰騰2022 Agile Summit 的攤位贈品
這份實體禮物也將我的記憶拉回 2018 年八月多

那時候我們 Standing 的大概流程是下面這樣(聲明:底下版本為團隊準備摸著石頭過河，且腳根本還沒濕的早早期版本)

1. PO 會將這個 Sprint 要做的 Sprint Backlog 整理在 trello
2. PO 跟組員們進行講解同時完善這些單的 user story
3. 將這些 Sprint Backlog 進行 story point 與 priority 的排序
4. 根據步驟 3 整理出來的清單與順序來開立 Task
5. 逐個討論此 Task 可能需要花費的時數，並且維護他們的 acceptacne(同步到 MantisBT)

其中 步驟 3 與步驟 5 我們團隊使用的就是這種 planning poker 來舉牌(我們也是選擇費氏數列來當基準)

於是乎我們就會針對這些任務們來進行估點
Sprint Backlog 倒是沒有什麼懸念 原本 PO 給的點數通常都會照用
畢竟這也只是一個相對規模的一個粗估
但 Task 的點數就有點刺激了
在當時對於此項流程的誤解，以及因為每個人的開發能力都不同
所以往往在討論這段的時候
都會遇到

大家對於這張 SD 單的預估是幾點... 3、2、1 舉牌

13，8，5，8，8，8，13，X

此時我們就會依照最低的先講，他為何預估 5 點
他可能就會說

這個案例之前某某某做過，可以參考那邊的程式碼

接下來則是換最高的13點發表他們的疑慮
然後再次舉牌

8，8，8，8，8，8，13，8

起初我們認為在這方面的共識一定要達到非常一致，所以往往在說服那最後一人時花費了不少心力
因為總是有那麼幾位 點數戰神 在捍衛著他心目中的理想數字

(就不太好意思說為什麼 burndown 會在第三天開始 因為 Planning 花了兩天)

經過不斷地迭代

為了討論效率與預估精準度我們流程上也有了不少的變化

1. PO 會將這個 Sprint 要做的 Sprint Backlog 整理在 Azure DevOps(沒錯，我們改用微軟雲)
2. PO 跟組員們進行第一次講解，並且說明優先順序
3. 將這些 Sprint Backlog 進行分組，並且將組員分派兩組人進行展開討論 (註.一)
4. 根據步驟 3 分類出來的 PBI 進行展開，開立 Task，並且維護他們的 acceptacne(同時一定程度的往下看 code ，讓預估更有把握)
5. 分組討論完畢時，再一起逐個過一次狀態，團隊沒有異議後則定案 (註.二)

註一：因為通常在開會討論時，發言的總都是固定班底。分組討論可以有效讓平常相對沈默的組員參與討論，然後遇到不確認的地方立馬請 PO 來解釋。
註二：在最後確認分組討論結果時，若對時數有異議也是在此刻喬定，並且在沒有共識的 Task 才會進行舉牌。 舉牌時，也僅會將第一輪的最高與最低進行發言後續再次投票則取中間值。

雖然我們目前乃在河中央持續摸索，致力往更好的方法邁進，但會議時長的問題已經解決了
畢竟 Planning 太久也會導致人員的精神耗弱

參考資料：
無